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Cell Updates in a UMTS Terrestrial Radio Access Network 
Fipiri nf the Invention 

5 The present invention relates to the handling of cell updates at the Iur interface of a 
UMTS Terrestrial Radio Access Network (UTRAN), the Iur interface being the 
interface between Radio Network Controllers (RNCs) of the UTRAN. 



Background to the Invention 
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The European Telecommunications Standardisation Institute (ETSI) is currently in the 
process of standardising a new set of protocols for mobile telecommunications systems. 
The set of protocols is known collectively as the Universal Mobile Telecommunications 
System (UMTS). The architecture of a UMTS network is based upon a UMTS core 

15 network and a UMTS Terrestrial Radio Access Network (UTRAN). The UTRAN 
comprises a number of Radio Network Controllers (RNCs), each of which is coupled to 
a set of neighbouring Base Transceiver Stations (BTSs) or Node Bs. Each Node B is 
responsible for a given geographical area or cell, and the controlling RNC is responsible 
for routing user and signalling data between that Node B and the core network. The 

20 interface between an RNC and a Node B is referred to as the Iu interface. A general 
outline of the UTRAN is given in Technical Specification TS 25.401 (UTRAN overall 
description) of the 3rd Generation Partnership Project, 3 GPP. 

User and signalling data may be carried between an RNC and a mobile terminal 
25 (referred to in UTRAN as User Equipment (UE)) using Radio Bearers (RBs). 
Typically, a mobile terminal is allocated one or more RBs, each of which is capable of 
carrying a flow of user or signalling data. At a Radio Link Control (RLC) entity, RBs 
are mapped onto respective logical channels. At a Media Access Control (MAC) entity, 
a set of logical channels is mapped in turn onto a transport channel, of which there are 
30 two types: a •'common- transport channel which is shared by different mobile terminals 
and a "dedicated" transport channel which is allocated to a single mobile terminal. One 
type of common channel is a Forward Access CHannel (FACH). Several transport 
channels (e.g. FACHs) are in turn mapped at the physical layer onto a Secondary 



2 

Common Control Physical CHannel (S-CCPCH) for transmission over the air interface 
between a Node B and a mobile terminal. 



When a mobile terminal registers with an RNC, via a Node B, that RNC acts at least 
5 initially as both the serving and controlling RNC for the mobile terminal. The RNC 
both controls the air interface radio resources and terminates the layer 3 intelligence 
(Radio Resource Control (RRC) protocol), routing data associated with the mobile 
terminal directly to and from the core network. Figure 1 illustrates the protocol model 
for the FACH transport channel when the serving and controlling RNCs are coincident 

10 and where Uu indicates the interface between the UTRAN and the mobile terminal 
CUE), and Iub indicates the interface between the RNC and a Node B. It will be 
appreciated that the MAC (MAC-c) entity in the RNC transfers MAC-c Packet Data 
Units (PDUs) to the peer MAC-c entity at the mobile terminal, using the services of the 
FACH Frame Protocol (FACH FP) entity between the RNC and the Node B. The 

15 FACH FP entity adds header information to the MAC-c PDUs to form FACH FP PDUs 
which are transported to the NodeB over an AAL2 (or other transport mechanism) 
connection. An interworking function at the Node B interworks the FACH frame 
received by the FACH FP entity into the PHY entity. 

20 Consider now the situation which arises when a mobile terminal leaves the area covered 
by a RNC with which the terminal is registered, and enters the area covered by a second 
RNC. Under the UTRAN protocols, the RRC remains terminated at the first RNC 
whilst the terminal takes advantage of a cell and common transport channel of the 
second RNC. Thus, the first RNC remains as the serving RNC with a connection to the 

25 core network whilst the second RNC becomes the controlling RNC. The controlling 
RNC is in control of the NodeB where the mobile terminal is located and in particular 
of the logical resources (transport channels) at that Node B. In this scenario the 
controlling RNC is referred to as a "drift" RNC (the controlling RNC will also be acting 
as a serving RNC for mobile terminals registered with that RNC). The protocol model 

30 for the FACH transport channel when the serving and controlling RNCs are separate is 
illustrated in Figure 2. It will be noted that a new interface Iur is exposed between the 
serving and the controlling RNCs. The RNSAP protocol is used for control plane 
signalling on the Iur interface. 
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When a mobile terminal first moves into the coverage area of the (new) DRNC, the 
mobile terminal must send an RRC Cell Update message to the SRNC to inform the 
SRNC of its new location. The RRC Cell Update message (L3 information) is 

5 forwarded by the DRNC to the SRNC using the RNSAP UL Signalling Transfer 
message. Upon receipt of a Cell Update, the SRNC must determine the configuration 
(scheduling priority, MAC-c/sh SDU length(s), and initial window size) of the FACH 
transport channel used by the DRNC for the cell to which the update relates. According 
to the current standard, the SRNC responds to receipt of a Cell Update by sending a 

10 RNSAP Common Transport Channel Resource Request message to the DRNC over the 
Iur interface. The DRNC responds with a RNSAP Common Transport Channel 
Resource Response message containing the configuration information. 
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In some network configurations, the FACH transport channel configuration may be the 
same for all cells of an RNC In other network configurations, the configuration may 
differ from cell to cell. The current standard handles this situation by performing the 
RNSAP procedure (request and response sequence) each time a Cell Update is received 
at the SRNC over the Iur interface, i.e. for the first and subsequent cell updates. 

20 Summary o f the Invention 

The approach adopted by the current standard has two main disadvantages. Firstly, the 
RNSAP exchange procedure introduces a delay into the cell update procedure. This 
may cause an interruption in the service provided to a mobile terminal and results in a 
25 less than optimal use of radio resources. Secondly, the procedure increases the 
signalling load on the Iur interface. In communications networks, a greater signalling 
load often results in higher infrastructure costs. 

According to a first aspect of the present invention there is provided, in a UMTS radio 
30 access network, a method of informing a serving RNC, SRNC, of the FACH transport 
channel configuration allocated by a drift RNC, DRNC, to user equipment, UE, the 
method comprising: 



4 

including in a RNSAP message sent from the DRNC to the SRNC, an 
information element indicating whether FACH flow control information contained in 
the response is unique to the DRNC cell, or whether the information is common to all of 
the cells of the DRNC, 

5 wherein if said information element indicates that the information is common to 

ail of the cells of the DRNC, the SRNC does not perform the RNSAP Common 
Transport Channel Resources Initialisation procedure, request/response sequence, for 
Cell Update messages subsequently received from the DRNC. 

10 In one embodiment of the invention, said RNSAP message is sent as part of a RNSAP 
Common Transport Channel Resources Initialisation procedure between the SRNC and 
the DRNC. 

Only in the event that the RNSAP Common Transport Channel Resource Response 
15 message indicates that the FACH flow control information is not common to all cells 
will the RNSAP Common Transport Channel Resources Initialisation procedure be 
repeated for subsequent cell updates corresponding to movement of the HE between two 
cells of the DRNC. Embodiments of the present invention both speed up the cell update 
procedure when a DRNC is involved and reduce the volume of signalling traffic over 
20 the Iur interface. 

In one embodiment of the present invention, the RNSAP procedure is performed when 
the UE first moves into a cell of the DRNC and following the forwarding of an RRC 
Cell Update message from the DRNC to the SRNC using the RNSAP Uplink Signalling 
25 Transfer procedure, the procedure comprising sending a RNSAP Common Transport 
Channel Resource Request message from the SRNC to the DRNC, and sending a 
RNSAP Common Transport Channel Resource Response message from the DRNC to 
the SRNC, one of said Cell Update message and said response containing said 
information element. 



Brief Description of the Drawings 
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Figure 1 illustrates a protocol model for a FACH transport channel when serving and 
controlling RNCs of the UTRAN are coincident; 

Figure 2 illustrates a protocol model for a FACH transport channel when serving and 

controlling RNCs of the UTRAN are separate; 

Figure 3 illustrates schematically a part of a UMTS network; 

Figure 4 is a flow diagram illustrating a method of handling cell updates via Iur in the 
UMTS network of Figure 3; and 

Figure 5 illustrates the flow of signalling information related to a cell update between a 
DRNC and a SRNC. 

retailed Description of a Preferr ed Embodiment 



Protocol models for the FACH transport channel of a UMTS network have been 
described with reference to Figures 1 and 2 for the cases where the serving RNC and 

1 5 controlling RNC are both coincident and separate. Figure 3 illustrates a part of a UMTS 
network comprising a core network 1 and a UMTS terrestrial radio access network 
(UTRAN) 2. Shown in the UTRAN 2 are a pair of Radio Network Controllers (RNCs) 
4,5, each of which has control of a set of Node Bs 6. Each Node B 6 provides radio 
coverage of a particular geographic cell, with the cells of neighbouring Node Bs 

20 overlapping. 

In the scenario illustrated in Figure 3, a UE 7 is shown communicating with one of the 
Node Bs of a first of the RNCs 4. The UE is assumed to move from the coverage area 
of the Node B of the first RNC 4 into the coverage area of a Node B of the second RNC 

25 5. The effect of the UE 7 roaming in this way is to cause the UE to take advantage of 
common transport channels (RACH/FACH) of the second RNC 5, the drift RNC 
(DRNC). As described above, the RRC protocol remains terminated at the first RNC, 
the serving RNC (SRNC). The UE 7 will send an RRC Cell Update message to the 
SRNC 4 to inform the SRNC of its new location. This message is sent via the DRNC 5 

30 across the Iub and Iur interfaces (and is the first connection between the UE and the 
DRNC). 



6 

The Cell Update message contains the U-RNTI (SRNC Id + RNTI (Radio Network 
Temporary Identity)) which identifies the UE within UTRAN. At reception of the Cell 
Update message, the DRNC checks the U-RNTI. As the UE is not registered in the 
DRNC, the DRNC forwards the Cell Update message, using the RNSAP Uplink 
5 Signalling Transfer message, to the SRNC based on the SRNC Id in the U-RNTI. 

When the SRNC 4 receives the first Cell Update message from the DRNC, the SRNC 4 
updates its cell location register, and initiates the RNSAP Common Transport Channel 
Resources Initialisation procedure. This involves the sending of a RNSAP Common 
10 Transport Channel Resource Request to the DRNC. This message is a request to 
establish the user plane towards the DRNC 5 and for the DRNC to return to the SRNC 4 
the FACH transport channel configuration for the cell in which the UE 7 is now located. 
As already stated above this configuration information includes the scheduling priority, 
MAC-c/sh SDU length(s), and initial window size. 

15 

The DRNC 5 responds to receipt of the RNSAP request message by generating and 
returning to the SRNC 4 a RNSAP Common Transport Channel Resource Response. 
This message has the following structure: 
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20 

where the presence field indicates whether or not the information elements of the 
message are mandatory (M) or optional (O). 

The RNSAP response message includes an additional information element (IE) referred 
25 to as "Cell Unique FACH Flow Control Info**. This element contains a flag which can 



be set to yes to indicate that the FACH transport channel configurations for all of the 
cells of the DRNC 5 are the same, or no to indicate that the configuration differs from 
cell to cell- The flag is set by the DRNC 5. It is noted that whilst in the above table, the 
additional IE is indicated as being mandatory, this need not be so and it may be included 
5 as an optional feature. 

When the RNSAP response is received by the SRNC 4, the Cell Unique FACH Flow 
Control Info IE is analysed. If the IE is set to yes, the SRNC 4 records the fact that it 
must execute the RNSAP Common Transport Channel Resource Initialisation procedure 
10 for every subsequent cell update in the DRNC 5. If the IE is set to no, the SRNC 4 
records the fact that the procedure is not needed for subsequent cell updates within the 
DRNC 5. 

Figure 4 is a flow diagram further illustrating the method described above. Figure 5 
1 5 illustrates the flow of signalling information over the Iur interface. 

It will be appreciated by the person of skill in the art that various modifications may be 
made to the above described embodiments without departing from the scope of the 
present invention. For example, it is possible that a connection between the UE and the 

20 DRNC may exist prior to the first cell update. If the UE is using dedicated channels 
(DCHs) via the DRNC, the SRNC may decide to perform a channel switch from DCH 
to FACH (e.g. if the UE has only a best effort packet data RAB and the traffic activity is 
low). In this case the SRNC may: a) select the target cell for the UE when switching to 
FACH; or b) force the UE to perform a cell update (in this case the target cell is selected 

25 by the UE) before switching to FACH. The SRNC indicates in RRC signalling to the 
UE whether the UE shall use a cell selected by the SRNC (alternative a) or perform a 
cell update (alternative b). In alternative a, the SRNC will perform the RNSAP 
Common Transport Channel Resource Initiation procedure without first having received 
a cell update from the UE via the DRNC. In alternative b, the RNSAP Common 

30 Transport Channel Resource Initialisation procedure follows a cell update. 
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Claims 

1 . In a UMTS radio access network, a method of informing a serving RNC, SRNC, 
of the FACH transport channel configuration allocated by a drift RNC, DRNC, to user 
5 equipment, UE, the method comprising: 

including in a RNSAP message sent from the DRNC to the SRNC, an 
information element indicating whether FACH flow control information contained in 
the response is unique to the DRNC cell, or whether the information is common to all of 
the cells of the DRNC, 

10 wherein if said information element indicates that the information is common to 

all of the cells of the DRNC, the SRNC does not perform the RNSAP Common 
Transport Channel Resources Initialisation procedure, request/response sequence, for 
Cell Update messages subsequently received from the DRNC. 

15 2. A method according to claim 1, wherein said RNSAP message is sent as part of 
a RNSAP Common Transport Channel Resources Initialisation procedure between the 
SRNC and the DRNC. 

3. A method according to claim 2 and comprising performing the RNSAP 
20 procedure when the UE first moves into a cell of the DRNC and following the 

forwarding of an RRC Cell Update message from the DRNC to the SRNC using the 
RNSAP Uplink Signalling Transfer procedure, the procedure comprising sending a 
RNSAP Common Transport Channel Resource Request message from the SRNC to the 
DRNC, and sending a RNSAP Common Transport Channel Resource Response 
25 message from the DRNC to the SRNC, one of said Cell Update message and said 
response containing said information element. 

4. A method according to claim 1, wherein said RNSAP procedure is carried out as 
part of a channel switch, from a DCH to a FACH. 

30 

5. A method according to claim 1, wherein said RNSAP procedure follows receipt 
of a cell update message from the UE at the SRNC. 



A Radio Network Controller for use in a UTRAN and comprising processing 
for implementing the method of any one of the preceding claims. 
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